This vulnerability allows local attackers to escalate privileges on affected installations of JupyterLab. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability. Additionally, the vulnerability is triggered only when a target user makes use of the product. The ZDI has assigned a CVSS rating of 7.3. The following CVEs are assigned: CVE-2025-30167.

Impact

On Windows, the shared %PROGRAMDATA% directory is searched for configuration files (SYSTEMCONFIGPATH and SYSTEMJUPYTERPATH), which may allow users to create configuration files affecting other users.

Only shared Windows systems with multiple users and unprotected %PROGRAMDATA% are affected.

Mitigations

- upgrade to jupytercore>=5.8.1 (5.8.0 is patched but breaks jupyter-server) , or - as administrator, modify the permissions on the %PROGRAMDATA% directory so it is not writable by unauthorized users, or - as administrator, create the %PROGRAMDATA%\jupyter directory with appropriately restrictive permissions, or - as user or administrator, set the %PROGRAMDATA% environment variable to a directory with appropriately restrictive permissions (e.g. controlled by administrators or the current user)

Credit

Reported via Trend Micro Zero Day Initiative as ZDI-CAN-25932

Overview

On many platforms, a third party can create a Git repository under a name that includes a shell command substitution [^1] string in the syntax $(<command>). These directory names are allowed in macOS and a majority of Linux distributions [^2]. If a user starts jupyter-lab in a parent directory of this inappropriately-named Git repository, opens it, and clicks "Git > Open Git Repository in Terminal" from the menu bar, then the injected command <command> is run in the user's shell without the user's permission.

This issue is occurring because when that menu entry is clicked, jupyterlab-git opens the terminal and runs cd <git-repo-path> through the shell to set the current directory [^3]. Doing so runs any command substitution strings present in the directory name, which leads to the command injection issue described here. A previous patch provided an incomplete fix [^4].

[^1]: https://www.gnu.org/software/bash/manual/htmlnode/Command-Substitution.html [^2]: https://www.gnu.org/software/libc/manual/htmlnode/File-Name-Portability.html [^3]: https://github.com/jupyterlab/jupyterlab-git/blob/7eb3b06f0092223bd5494688ec264527bbeb2195/src/commandsAndMenu.tsx#L175-L184 [^4]: https://github.com/jupyterlab/jupyterlab-git/pull/1196

Scope of Impact

This issue allows for arbitrary code execution via command injection. A wide range of actions are permitted by this issue, including but not limited to: modifying files, exfiltrating data, halting services, or compromising the server's security rules.

We have scanned the source code of jupyterlab-git for other command injection risks, and have not found any at the time of writing.

This issue was reproduced on the latest release of jupyterlab-git, v0.51.0. The steps taken to reproduce this issue are described in the "Proof-of-concept" section below.

Proof-of-concept

1. Create a new directory via mkdir test/ && cd test/.

2. Create a new Git repository under test/ with a command substitution string in the directory name by running these commands:

mkdir '$(touch pwned.txt)' cd '$(touch pwned.txt)/' git init cd ..

3. Start JupyterLab from test/ by running jupyter lab. 4. With JupyterLab open in the browser, double click on $(touch pwned.txt) in the file browser. 5. From the top menu bar, click "Git > Open Git Repository in Terminal". 6. Verify that pwned.txt is created under test/. This demonstrates the command injection issue described here.

Proof-of-concept mitigation

The issue can be mitigated by the patch shown below.

<details><summary>Patch (click to expand)</summary>

diff diff --git a/src/commandsAndMenu.tsx b/src/commandsAndMenu.tsx index 3779a6c..71ddcea 100644 --- a/src/commandsAndMenu.tsx +++ b/src/commandsAndMenu.tsx @@ -164,31 +164,13 @@ export function addCommands( label: trans.('Open Git Repository in Terminal'), caption: trans.('Open a New Terminal to the Git Repository'), execute: async args => { - const main = (await commands.execute( - 'terminal:create-new', - args - )) as MainAreaWidget<ITerminal.ITerminal>; + const cwd = gitModel.pathRepository; + const main = (await commands.execute('terminal:create-new', { + ...args, + cwd + })) as MainAreaWidget<ITerminal.ITerminal>; - try { - if (gitModel.pathRepository !== null) { - const terminal = main.content; - terminal.session.send({ - type: 'stdin', - content: [ - cd "${gitModel.pathRepository - .split('"') - .join('\\"') - .split('') - .join('\\')}"\n - ] - }); - } - - return main; - } catch (e) { - console.error(e); - main.dispose(); - } + return main; </details>

This patch removes the cd <git-repo-path> shell command that causes the issue. To preserve the existing behavior, the cwd argument is set to <git-repo-path> when a terminal session is created via the terminal:create-new JupyterLab command. This preserves the existing application behavior while mitigating the command injection issue.

We have verified that this patch works when applied to a local installation of jupyterlab-git. We have also verified that the cwd argument is available in all versions of JupyterLab 4, so this patch should be fully backwards-compatible.

Workarounds

We recommend that users upgrade to the patched versions listed on this GHSA. However, if a user is unable to upgrade, there are 3 different ways to mitigate this vulnerability without upgrading to a patch.

1. Disable terminals on jupyter-server level: c.ServerApp.terminalsenabled = False

2. Disable the terminals server extension: jupyter server extension disable jupyterserverterminals

3. Disable the lab extension: jupyter labextension disable @jupyterlab/terminal-extension

JupyterLab extension template is a copier template for JupyterLab extensions. Repositories created using this template with test option include update-integration-tests.yml workflow which has an RCE vulnerability. Extension authors hosting their code on GitHub are urged to upgrade the template to the latest version. Users who made changes to update-integration-tests.yml, accept overwriting of this file and re-apply your changes later. Users may wish to temporarily disable GitHub Actions while working on the upgrade. We recommend rebasing all open pull requests from untrusted users as actions may run using the version from the main branch at the time when the pull request was created. Users who are upgrading from template version prior to 4.3.0 may wish to leave out proposed changes to the release workflow for now as it requires additional configuration.